Methods and apparatus for early remittance issue detection

ABSTRACT

Methods and apparatus for detection of remittance issues associated with multiple medical billing claims. Exemplary methods and apparatus involve comparing an expected open rate to an actual open rate for at least one payer to identify at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate. Identified bumps are categorized as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range. A user interface displays the pattern of remittance to a user to enable the user to determine an appropriate action to correct an underlying cause of the detected remittance issues.

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application Ser. No. 61/166,351, entitled “METHODS AND APPARATUS FOR QUEUE-BASED CLUSTER ANALYSIS,” filed on Apr. 3, 2009, which is herein incorporated by reference in its entirety.

TECHNICAL FIELD

The present invention relates generally to the processing of entries in a queue, and more specifically relates to identifying a cluster of entries in the queue in order to process the entries in the cluster at the same time.

BACKGROUND

Lists of records or queues are commonly used to collect and analyze data for a variety of applications. For example, queues may be used to store and track the status of claims issued by a medical services provider. A typical medical services provider, or a third-party acting on behalf of the medical services provider, processes a large volume of claims detailing expenses incurred by patients treated by the medical services provider. Each of these claims includes information and costs associated with one or more procedures or services provided to the patient, and which the medical service provider would like to recover payment. For many patients, payment is recovered by transmitting the claims to the patient's insurance provider or other payer who, in turn, evaluates the charges on the claim and remits the appropriate payment to the medical services provider. Ensuring that this payment process operates smoothly is important to the medical services provider to facilitate payment for the medical service provider's services in a timely manner.

Medical services providers process hundreds or thousands of claims a day. One way to facilitate tracking the status of these claims is to enter the claims as entries in a database which keeps track of, among other things, when the claims were sent and when remittance was received. Due to the large volume of claims being processed, a medical services provider may not receive a response for some claims even though the claims were submitted several weeks or months prior. For each claim in which a response was not received, a communication (e.g., a telephone call) is made to the payer in order to determine why there was no response. If even a relatively small percentage of the claims do not receive a response, the number of follow-up calls required may be quite large, resulting in a process that is both time-consuming and costly for the medical services provider.

SUMMARY

Some embodiments of the invention are directed to detection of remittance issues early in a billing cycle to enable a user to determine appropriate actions to correct an underlying cause of the detected remittance issues.

Some embodiments of the invention are directed to a method of detecting remittance issues associated with a plurality of medical billing claims. The method comprises acts of calculating, with at least one processor, an expected open rate for at least one payer based, at least in part, on historical claim billing information collected for a plurality of payers and/or a plurality of providers in a claim billing system; determining an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identifying at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorizing the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.

Some embodiments of the invention are directed to at least one computer-readable storage medium encoded with a plurality of instructions, that when executed by a computer, perform a method of detecting remittance issues associated with a plurality of medical billing claims. The method comprises acts of calculating an expected open rate for at least one payer based, at least in part, on historical claim billing information collected for a plurality of payers and/or a plurality of providers in a claim billing system; determining an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identifying at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorizing the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.

Some embodiments of the invention are directed to a medical billing claim processing system comprising at least one processor. The at least one processor is programmed to calculate an expected open rate for at least one payer based, at least in part, on historical claim billing information collected for a plurality of payers and/or a plurality of providers in a claim billing system; determine an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identify at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorize the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.

It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like reference character. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

FIG. 1 is a flow chart queue-based cluster analysis process according to some embodiments of the invention;

FIG. 2 is a flow chart of a cluster identification process according to some embodiments of the invention;

FIG. 3 is a flow chart of an early remittance issue detection process for use with some embodiments of the invention;

FIG. 4 is a schematic illustrating an exemplary output of the early remittance issue detection process of FIG. 3;

FIGS. 5A-5C are flow charts illustrating scoring strategies according to some embodiments of the invention;

FIG. 6 is a display of a user interface produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 7 is a display of a cluster report produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 8 is a display of a cluster composition report produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 9 is a display of a cluster record report produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 10 is a display of individual claim information produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 11 is a display of detailed claim information produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 12 is a display of a claim processing interface produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIGS. 13A and 13B are respectively a display of a user interface for entering notes and a display of a user interface for editing claim information, both of which are produced by portions of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 14 is a display of a user interface for detecting claims outside of a worked cluster, the user interface being produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 15 is a display of an administrative user interface produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 16 is a display of a report generating interface produced by a portion of a software program used to analyze clusters generated in accordance with some embodiments of the invention;

FIG. 17 is a display of a user interface for illustrating a pattern of remittance for at least one payer in accordance with some embodiments of the invention;

FIG. 18 is a display of a user interface illustrating an exemplary “Remittance Never Received” pattern of remittance in accordance with some embodiments of the invention;

FIG. 19 is an alternate display of a user interface illustrating the exemplary “Remittance Never Received” pattern of remittance shown in FIG. 18;

FIG. 20 is a display of a user interface illustrating an exemplary “Remittance Cessation” pattern of remittance in accordance with some embodiments of the invention;

FIG. 21 is a display of a user interface illustrating an exemplary “Specific Remittance Failure” pattern of remittance in accordance with some embodiments of the invention;

FIG. 22 is an alternate display of a user interface illustrating the exemplary “Specific Remittance Failure” pattern of remittance shown in FIG. 21 grouped by billing batch;

FIG. 23 is an alternate display of a user interface illustrating the exemplary “Specific Remittance Failure” pattern of remittance shown in FIGS. 21 and 22 grouped by claim format;

FIG. 24 is a display of a user interface illustrating an exemplary “Failed Crossover” pattern of remittance in accordance with some embodiments of the invention;

FIG. 25 is an alternate display of a user interface illustrating the exemplary “Failed Crossover” pattern of remittance shown in FIG. 24 grouped by context; and

FIG. 26 is an alternate display of a user interface illustrating the exemplary “Failed Crossover” pattern of remittance shown in FIGS. 24 and 25 grouped by context.

DETAILED DESCRIPTION

The present disclosure generally relates to inventive methods and apparatus for processing entries in a queue, and more specifically to identifying and analyzing clusters of entries in the queue that share common features. A typical medical billing practice processes hundreds or thousands of claims a day by transmitting the claims to a payer such as an insurance company or clearinghouse. The payer usually returns a remittance or denial. However, a certain percentage of the submitted claims do not receive a response from the payer and follow-up, called “claim tracking,” is performed to ensure that the corresponding medical service provider receives proper payment for their services. The status of all submitted claims may be tracked by including information about the claims as entries in an electronic queue such as a database, or in any other suitable electronic format. For each claim that has not received a response after a predetermined amount of time, a follow-up communication to the payer may be initiated to determine the source of the non-response. As the volume of claims processed by a medical billing practice increases, the number of follow-up communications and the length of time before the medical service provider is paid increases.

Applicants have recognized and appreciated that multiple entries in a queue may share common features, and that by grouping the multiple entries together into a cluster, the multiple entries in the cluster may be processed in parallel. For example, if the queue comprises claims for which a response has not been received from a payer, a common root cause relating to why the response has not been received may underlie several of the claims in the queue. Identifying clusters in a queue which may share a common root cause, and addressing the common root cause may obviate the need to follow-up on each of the claims in the queue separately resulting in an efficient problem resolution process.

To this end, some embodiments of the invention are directed to methods and apparatus for identifying candidate clusters of entries (e.g., claims which have not received a response) in a queue that share at least one common feature, and analyzing the candidate clusters to determine a common underlying cause (e.g., why a response has not been received for the claims in the cluster). An exemplary illustration of a method for processing claims in a queue is provided in FIG. 1. In act 102, claims belonging to a particular category are collected into a queue. For example, each claim that is submitted to a payer may have an estimated time window within which a response is typically received. When a response is not received within this time window, the status of the claim may be changed (e.g., to “Followup”) to indicate that a follow-up communication should commence. The status of a claim may be stored as part of the entry for the claim in a queue or in any other suitable way, such as metadata associated with the entry for the claim. All claims in which the status was changed to “Followup” over the course of a predetermined time frame may be collected into a queue in act 102 in order to be processed. For example, all claims marked as “Followup” within the last sixty days may be collected into a queue for further analysis. It should be appreciated that a particular category used to form the queue in act 102 is not limited to claims without a payer response, but the particular category may alternatively be related to denied claims, claims on hold, or any other issue which would benefit from further investigation to determine a common root cause.

After forming a queue of claims in act 102, the claims in the queue are grouped based on shared characteristics in act 104, as described below in more detail. Although some claims may be included in only a single group, other claims may be included in more than one group provided that the claims have shared characteristics with claims in multiple groups. Groups of claims that meet certain criteria are classified as clusters in act 106. In some embodiments, groups may need to comprise a minimum number of claims to be considered a cluster. In addition to a minimum number of claims, other exemplary criteria may also be used when generating clusters and embodiments of the invention are not limited in this respect.

Clusters generated in act 106 are analyzed in act 108 to identify at least one common root cause why the claims have been included in the particular category that is being investigated (e.g., submitted claims without a response). Exemplary ways of analyzing clusters according to some embodiments of the invention are described in more detail below.

After a common root cause has been identified for claims in a cluster, the root cause is addressed to remedy the problem. For example, the common root cause identified in act 108 may be an incorrect pay-to address. In this example, the pay-to address may be corrected in act 110, and the claims in the cluster may be resubmitted to the payer with the corrected pay-to address. It should be appreciated that the common root cause may be addressed by a user with or without directed guidance, or the process may be automated. For example, in some embodiments, options of how to address a root cause issue may be presented to a user and the user may choose from among the options. The options may be presented as a decision tree on a user interface, or in any other suitable way. In other embodiments, software executed on a computer may be used to automatically select an option for addressing the root cause issue without user intervention.

The status of the claims in a cluster that has been analyzed or “worked” is updated in act 112. For example, the status of the claims in a processed cluster may be changed from “Followup” to some other status to indicate that follow-up has been performed on all of the claims in the cluster. Thus, only a limited number of follow-up communications are necessary to process all of the claims in a cluster due to their shared common root cause.

In some embodiments, information about a resolution process for the root cause of a cluster is recorded so future claims having similar attributes may be processed in the same way as the claims in the cluster. The resolution process may be recorded by storing a cluster pattern and the root cause identified for the claims in a cluster for a predetermined amount of time (e.g., one year). By storing this information, new claims that arise during the predetermined amount of time are processed similarly to the claims in the cluster, but new claims that arise outside of this time window are handled differently. It should be appreciated that information about a resolution process may be stored in any suitable manner and for any desired length of time and embodiments of the invention are not limited in this respect.

In some embodiments, claims that do not receive a timely response from a payer are identified, and for each claim that is identified, information that may be useful in determining a common cause is collected. Table 1 illustrates exemplary information that may be collected for each claim that is identified, although other information may also be collected and embodiments of the invention are not limited in this respect.

In some embodiments, determining when a claim should be included in a queue for clustering analysis may be performed by setting an alarm date for each claim that is submitted to a payer. If a response is not received from the payer by the alarm date, the alarm is triggered and the status of the claim is changed to Followup. Alternatively, an alarm may be deactivated if a response is received prior to the alarm date. Alarm dates may be determined based on a number of factors including, but not limited to, historical performance data for a payer, the complexity of the claim, the time of year when the claim is submitted, or any other factors which are related to a billing cycle. Although setting alarms is one example of a process for ensuring that claims are properly tracked, other methods may be used, and embodiments of the invention are not limited in this respect. For example, in some embodiments, claims that do not receive a response from a payer within a fixed amount of time, regardless of the payer's identity, may automatically be transferred to Followup status and may be used in the cluster analysis described above.

TABLE 1 Exemplary Information Collected for Claims Practice Provider Medical Group Department Insurance Package Insurance Reporting Category Enrollment Category Claim Submission Category Billed Date Billing Batch Batch Format EMC Receiver Date of Response (including Follow-up calls) Follow-up Call Result Code (if available) Claim Status Inquiry (CSI) Result Code (if available)

After information has been collected on at least some of the claims in the queue to be analyzed, cluster identification methods may be used to identify candidate clusters of claims that might be being processed incorrectly due to a shared root cause or problem.

A cluster identification process 200 in accordance with some embodiments of the invention is illustrated in FIG. 2. For the purposes of illustration, the cluster identification process 200 will be applied to the example provided above in which claims that have triggered an alarm due to the lack of a response from a payer are analyzed. The cluster identification process 200 is driven by a configurable set of “cluster patterns” that define a set of attributes that claims would have in common if the delay in payer response was due to the same root cause.

As described above, and illustrated as act 202, detailed information is collected for each claim in the queue used for cluster identification. This detailed information may be related to the attributes shown in Table 1 or any other suitable attributes that would assist in categorizing claims into clusters based on a common underlying cause. In some embodiments, detailed information may be stored in a denormalized table in a relational database, although the information may be stored in any other suitable form and embodiments of the invention are not limited in this respect.

After collecting the detailed information for each claim in act 202, the claims are grouped together along dimensions outlined by a set of predefined cluster patterns. The cluster patterns are indicative of a common root cause or problem. Exemplary cluster patterns, to which the embodiments of the invention are not limited, are shown in Table 2. Although only six cluster patterns are illustrated in Table 2, it should be appreciated that any attributes (including those in Table 1 or otherwise) may be combined to define cluster patterns and embodiments of the invention are not limited in this respect.

TABLE 2 Exemplary Cluster Patterns Billing Batch Insurance Reporting Category:: CSI Result Type Medical Group:: Batch Format:: Insurance Package Medical Group:: Batch Format:: Insurance Reporting Category (IRC) Medical Group:: Claim Submission Category Medical Group:: Insurance Reporting Category

For each defined cluster pattern, clusters are generated in act 204 based on the claims included in the queue. As described above, a claim may be included in the queue based on numerous criteria including, but not limited to, the claim's current status or if the status of the claim is anticipated to change in the near future. For example, in some embodiments, claims that have been changed to Followup status in the past sixty days may be included in the queue along with claims that are close to their alarm date. By also including claims that are close to their alarm date, these claims are dealt with proactively, rather than waiting until an alarm has been triggered.

In some embodiments, claims in the queue are grouped using the defined cluster patterns in a sequential manner. With reference to Table 2, which defines six cluster patterns, claims may first be grouped according to the attribute “Billing Batch,” and clusters based on this pattern are generated in act 204. After claims are grouped according to the attribute “Billing Batch,” it is determined in act 206 if there are other defined cluster patterns to be analyzed. If there are other defined cluster patterns, another cluster pattern is selected and claims are grouped according to the shared attributes in the new cluster pattern. For example, continuing the example above, claims may be grouped according to the next defined cluster pattern (e.g., Insurance Reporting Category::CSI Result in Table 2) and clusters may be generated based on these shared attributes. In some embodiments, the process continues until all defined cluster patterns have been analyzed, although in other embodiments only a subset of defined cluster patterns may be analyzed, for example, if the number of defined cluster patterns is large. If it is determined in act 206 that no other cluster patterns are to be analyzed, each of the clusters is screened according to predefined criteria to determine if the cluster should be analyzed or discarded.

Applicants have appreciated that it may be useful to only analyze clusters having a minimum number of claims (e.g., 100 claims), or at least to address clusters having a large number of claims first. Thus, in some embodiments, it is determined in act 208 if the number of claims in each cluster exceeds a predetermined threshold value. If the number of claims in the cluster does not exceed the threshold value, the cluster is eliminated in act 210 and it is determined in act 214 if there are more clusters to be screened. If it is determined in act 214 that there are more clusters to be screened, another cluster is selected and it is determined in act 208 if the number of claims in this cluster exceeds the threshold value.

An illustrative example of the above-described thresholding process is as follows: Cluster A generated based on the “Medical Group::Claim Submission Category” cluster pattern has 500 claims. The value of the attribute Medical Group is “ABC Medical Group” and the value of the attribute Claim Submission Category is “123 Submissions.” Cluster B generated based on the same cluster pattern has 5 claims, and has values of Medical Group=“DEF Medical Group” and Claim Submission Category=“456 Submissions.” If the threshold was set at 100 claims, cluster A would survive, but cluster B would be eliminated in act 210 because the number of claims in cluster B is too small to justify investigation through cluster analysis.

Other screening steps in addition to cluster size analysis may be included and embodiments of the invention are not limited in this respect. In some embodiments, clusters may be screened based on whether a pattern characteristic (i.e., cluster pattern and values) is too general to result from a single root cause. For example, a cluster generated based on the cluster pattern “Medical Group::Insurance Reporting Category” that refers to the “Legal” IRC may be eliminated because the “Legal” IRC refers to too wide a variety of insurance companies,” and it is likely that the claims in the cluster do not share the same root cause.

In some embodiments, when a potentially new cluster is identified, it may first be determined whether the potentially new cluster already exists in a database used to store the generated clusters. Determining if the potentially new cluster already exists reduces the possibility of duplicate clusters which may unnecessarily cause the same cluster to be worked multiple times.

In some embodiments, elimination of a cluster in act 210 results in the status of the claims in the cluster remaining unchanged (e.g., the claims in the cluster remain in Followup status), although in other embodiments, clusters that are eliminated may form a claim tracking queue in which each claim in the claim tracking queue is addressed by a follow-up communication in a one-by-one manner.

In some embodiments, claims may be segmented into tiers based on various characteristics, and different groups of users may be responsible for working claims in each tier. For example, claims that are eliminated from the cluster identification process and are placed in a claim tracking queue, may transition from one tier (e.g., the cluster ID tier) to a different tier (e.g., the claim tracking tier) so that ownership of the claims between the two groups is clearly indicated. It should be appreciated that any suitable communication mechanism may be used to communicate the ownership of claims worked by different groups of users, and the aforementioned description of a tier-based system is only one possible implementation.

Once it is determined that all of the clusters have been screened, the remaining clusters are classified as “Active” in act 216 and information about the cluster is added to a cluster database that, among other things, may be used to analyze future claims having similar attributes as described above.

In some embodiments, a relational database is used to store clusters and information about the clusters. Clusters may be stored as records in a clusterrecord table, and general information about the clusters may be entered as a single record in a clustergroup table. For example, the clustergroup table may include information such as the identifier and name of the cluster and whether it is “active cluster” or a “duplicate cluster.” As used herein, the term “duplicate cluster” is used to refer to a cluster which shares a predetermined percentage of claims with another cluster. Detailed information regarding component “key-value” pairs that define the cluster may be stored in a clustergroupvalue table. For example, the clustergroupvalue table may include information stating that the claims in the cluster have a Medical Group ID of 1 and a Claim Submission Category ID of 10. After storing a cluster in the relational database, claims embodied as cluster records in the relational database may be associated with the cluster.

As described above, some claims can belong to more than one cluster. For example, a claim can belong to one cluster generated based on the “Billing Batch” cluster pattern and another cluster generated based on the “Medical Group::Claim Submission Category” cluster pattern. To facilitate querying against clusters generated based on different cluster patterns, in some embodiments in which a relational database is employed, a bridge table may be created, which includes a record that lists the cluster record ID along with the ID of the cluster to which it belongs.

Applicants have recognized that some clusters may have a substantial amount of shared claims between them. Accordingly, in some embodiments, stored clusters may be reviewed for duplicates. Some clusters may be flagged as duplicates if they share a predetermined percentage of claims. In some instances, duplicate clusters may be identical, although in other instances duplicate clusters may only share a majority of their claims. Determining whether claims are duplicates may be performed in any suitable way and embodiments of the invention are not limited in this respect.

After the clusters have been added to the database, in some embodiments, the clusters are scored to determine a likelihood that the claims share a root cause issue. One or more algorithms, described in more detail below, may be used to determine the score for a cluster.

Applicants have recognized that cluster identification techniques according to embodiments of the present invention may also be useful in systems that assist multiple providers to receive payment from multiple payers. Such an system may be used, for example, by a third party who assists medical services providers in collecting payments for claims by submitting the claims to insurance companies or other payers on behalf of the medical services providers. The third party may use information that is gathered across multiple providers and payers to address common root cause issues that may arise in such systems.

To this end, another type of cluster identification analysis 300, for use with some embodiments of the invention is called “early remittance issue detection” and is illustrated in FIG. 3. In this approach, anomalies in a payer billing cycle are detected and categorized by comparing actual remittance returns to expected remittance returns. In early remittance issue detection, the survival distribution of claims at a particular payer across multiple providers is determined. Applicants have recognized that in systems with a large sample size (i.e., many providers), survival distributions can be estimated empirically across many dimensions including, but not limited to, medical group, individual provider, payer, claim format, and expected remittance format. For each of these dimensions, the empirical survival distributions may be compared to the actual survival distribution for a particular dimension set, and positive deviations or “bumps” (actual greater than empirical) may be identified and analyzed.

Empirical survival distributions may be determined based on any suitable information related to a claim billing history of providers and/or payers in a medical claim processing system. For example, claims sent on paper forms typically have significantly longer turn-around times than claims sent electronically (e.g., using ANSI 837 I/P forms), and claims remitted electronically (e.g., using ANSI 835 forms) typically have slightly faster turn-around times when combined with Electronic Funds Transfer (EFT). Based on this information, an upper envelope for acceptable durations for claims to reside at a payer may be determined. Actual claims billed within a predetermined time range (e.g., the last 120 days) may be analyzed to determine if the percentage of claims that have not received remittance (i.e., claims that are “open”) exceeds this upper envelope. The information output from this analysis may be provided via a user interface to a user to facilitate further analysis of specific claims or groups of claims identified by the early remittance detection system.

An exemplary early remittance issue detection process with reference to FIG. 3 is now described. In act 302, information about claims to be analyzed may be collected. In particular, a billing cycle for a claim may be established in act 302 by determining the beginning and/or end of the claim, and how the claim was resolved, if applicable. When a claim has not yet be received from a payer its billing cycle status may be referred to as “open”, and otherwise its billing cycle status may be referred to as “closed.” The claim information may be collected in any suitable way. For example, the claim information may be extracted from multiple data sources and the extracted data may be centralized. In some embodiments, each claim and billing event combination may be stored along with associated factors. Billing events may also be associated with remittance events to facilitate the calculation of empirical survival distributions, as described above. At least some of the information that may be collected in act 302 is illustrated in Table 3.

TABLE 3 Exemplary Claim Information Claim ID Transfer Type Practice Medical Group Department Billing Provider Insurance Package Insurance Reporting Category Enrollment Category Claim Submission Category Billed Date Billing Batch Batch Format Date Billing Event Ended Reason Why Billing Event Ended Remittance Format (Check or EFT) Remittance Advice Format Current Claim Status

In act 304, the information collected in act 302 may be used to calculate cumulative probability distributions for one or more combinations of payer, batch format, remittance format, remittance advice format, and/or other suitable claim information, for which remittance was received based, at least in part, on empirical return times. These cumulative probability distributions are also referred to herein as “expected open rates,” although it should be appreciated that the term “expected open rates” is not limited to a rate that is calculated using any particular statistical method. In act 306, the expected open rates may be compared to actual open rates for claims submitted within a predetermined time range, and instances where the actual open rates exceed the expected open rates may be identified as a bump. FIG. 4 illustrates an example of how one or more bumps may be identified in accordance with some embodiments of the invention.

The graph in FIG. 4 illustrates the empirical survival distribution 410 and actual survival distribution 420 for one provider/payer combination. As described above, “bumps” are located at positions where the actual survival distribution 420 exceeds the estimated survival distribution 410. For example, in the graph of FIG. 4, several bumps 430 a-430 d may be identified for further investigation.

After the one or more bumps are identified, each bump may be scored in act 308. It should be appreciated that any suitable technique for scoring bumps may be used and the scoring techniques discussed below are merely non-limiting examples. In some embodiments, a claim volume score, C(B), a dollar amount score, A(B), and a percentage of daily charges score, R(B), may be calculated for each bump, B, according to the following formulas:

C(B _(t))=1[{circumflex over (p)} _(t) ^(c) >p _(t)]({circumflex over (p)} _(t) ^(c) −p _(t))c _(t)

A(B _(t))=1[{circumflex over (p)} _(t) ^(a) >p _(t)]({circumflex over (p)} _(t) ^(a) −p _(t))a _(t)

R(B _(t))=A(B _(t))/ADC

where P_(t) is the expected open rate, {circumflex over (p)}_(t) ^(c) is the actual open rate for claims, {circumflex over (p)}_(t) ^(a) is the actual open rate for outstanding dollars, c_(t) is the claims in time period t, a_(t) is the amount billed in time period t, and ADC is the average daily charge.

Each of these scores may be designed to represent different aspects of remittance situations in order to facilitate early detection of remittance issues. For example, the claim volume score, C(B), relates to high claim volume situations, and tends to apply greater weights to large volume clients. The dollar amount score, A(B), relates to the actual charged amounts, and is designed to capture situations in which a few high dollar claims are outstanding. The percentage of daily charges score, R(B), relates to the size of a bump with respect to the overall charge volume of a client, which tends to reduce at least some of the differences between small volume clients and large volume clients.

In act 310, combinations of bumps may be considered to determine if multiple bumps are near each other and should be grouped. Grouping of bumps based, at least in part, on nearness of the bumps, may be accomplished using any suitable technique and aspects of the invention are not limited in this respect. For example, in some embodiments, bumps that are contiguous or near-contiguous in time may be grouped in act 312 and the process may return to act 308 for recalculation of scores based on the grouped bumps. In other embodiments, the nearness of bumps in act 310 may be determined using other criteria including, but not limited to, grouping based on providers of a same medical group, billing batches of a similar format, and transfertype. The process of grouping bumps may be referred to as “Clustering” and “Tree Pruning.”

After it has been determined in act 310 that there are no other near bumps, the bump or group of bumps may be categorized as an issue in act 314. Categorization of bumps and groups of bumps is described in more detail below. In act 316, it is determined if more bumps are to be categorized. If there are additional bump(s) to be categorized, the process returns to act 308 to calculate score(s) for the additional bump(s). When it has been determined that all of the bumps have been categorized, the process continues to act 318 to determine if one or more scores associated with an issue are above a predetermined threshold value. If it is determined that the score(s) are not above the threshold value, in act 320, the issue is eliminated from consideration. Otherwise, if it is determined in act 318 that the score(s) are above the threshold value, the issue may be stored (e.g., in a queue) for addressing. In act 322, it is determined whether scores for additional issues are to be compared to a predetermined threshold value. If it is determined that additional issues are to be considered, the process returns to act 318 where the score(s) for a new issue are compared to the predetermined threshold value. After scores for all of the issues have been compared to the threshold value, the underlying issues may be addressed in act 324. Although the exemplary process shown in FIG. 3 shows that underlying issues are stored (e.g., in a queue) prior to being addressed, in some embodiments one or more of the underlying issues may be addressed prior to comparing scores for each of the issues to a threshold value. For example, act 324 may alternatively occur after act 318 and prior to act 322 in some embodiments.

In some embodiments, the categorization of bumps may be facilitated using at least one user interface configured to display remittance information about claims that have been submitted to one or more payers. An example of a portion of a user interface that may be used in accordance with some embodiments of the invention is illustrated in FIG. 17. The exemplary user interface shown in FIG. 17 includes a plurality of graph regions and a plurality of selection regions for controlling various aspects of the graph regions. A user may interact with one or more of the graph regions and the section regions to change the information displayed to facilitate a determination and/or categorization of a remittance issue.

The exemplary user interface shown in FIG. 17 includes graphs 1710 and 1720, which display by billing date, the percentage of claims and the number of claims, respectively, by status. The darkly-shaded bars in graph 1710 indicate the percentage of claims that are still open (e.g., remittance not received). Selection region 1730 includes multiple controls and fields that a user may interact with to change the remittance information displayed in graphs 1710 and 1720. For example, remittance for a particular payer and/or claim format may be selected in selection region 1730, and these selections may be applied to graphs 1710 and 1720 to display only the information selected.

In addition to viewing remittance data on a date axis, the exemplary user interface shown in FIG. 17 also includes graph 1740, which displays the remittance information by payer. As with the graph 1710, the shading of bars in graph 1740 indicate a current status of claims for each payer. Selection region 1750 includes multiple fields and controls to change the remittance information displayed in graph 1740. For example, the displayed remittance information may be grouped by billing batch or payment method to facilitate a categorization of the remittance information as will be discussed in more detail below.

Although the selection areas 1730 and 1750 may be used to change the remittance information displayed in corresponding graphs 1710, 1720, and 1740, interaction by a user (e.g., mouse click, key press, etc.) with some portions of the graphs themselves may result in changing the displayed remittance information. For example, if a user selects a particular payer displayed in graph 1740, graphs 1710 and 1720 may be updated to reflect the remittance by date for the selected payer. Alternatively, a user may select one of the displayed bars in graph 1710 or graph 1720 corresponding to a particular day, and remittance information displayed in graph 1740 may be restricted to remittance information only for the day that is selected. Thus, the graphs may have the ability to drive each other to enable a quick exploration of the data to facilitate categorization. Although a specific implementation of a user interface for use with some embodiments of the invention has been described, it should be appreciated that any suitable user interface including any types of graphs and/or selection regions may be used and aspects of the invention are not limited in this respect.

Categorizing bumps will now be explained in more detail with reference to FIGS. 18-26. In some embodiments of the invention, bumps are classified into one of at least four categories. Applicants have recognized that in some circumstances, when a new provider is added to a system with multiple providers and payers, remittance for initial claims submitted to a payer by the provider may not be received for some time. This behavior is captured by the category “Remittance Never Received.” Bumps may be classified into this category if the bumps are contiguous in time, begin at the current date and show no remittance (i.e., have a no response probability value of 1) or very little remittance. An example of remittance information that falls within this type of category is illustrated in FIGS. 18 and 19. FIG. 18 illustrates an exemplary scenario in which a client has recently started submitting claims for payment, but very little remittance has been received. Visually, this pattern is indicated in graph 1810 by the shaded bars 1812 indicated that nearly 100% of remittance for claims submitted still have not been closed because remittance has not been received. The distribution of remittance for different payers is shown in graph 1820 and indicates that there may be remittance issues with particular payers that should be corrected to facilitate remittance.

FIG. 19 illustrates a cumulative comparison view of the remittance information shown in FIG. 18. This view of the data compares the percent of open claims with the upper envelope of expected remittance outstanding as described above to enable a user to determine when the remittance should have been received. For example, in the exemplary scenario shown in FIGS. 18 and 19, it is evident from graph 1900 that at least some remittance should have been received beginning eight days from billing (e.g., the first bar from the right side of graph 1900 with any shading is bar 1910, which is the eighth bar from the right of the graph 1900). However, no remittance has been received in the entire twenty-five business days of billing claims. Grouping based on claim format, as shown in graph 1920 may help facilitate determining a solution to the remittance issue (e.g., if the client is submitting all claims using paper rather than electronically, remittance may take longer than expected). By interacting with the user interface to perform an analysis of the remittance information displayed in FIGS. 18 and 19, a user may be able to detect and resolve remittance issues earlier than with existing remittance detection systems.

Applicants have also recognized that certain providers that have been receiving remittance for some time may suddenly stop receiving remittance from a particular payer. This behavior is captured by the category “Remittance Cessation.” One possible reason why remittance cessation occurs is due to the provider signing up for Electronic Funds Transfer (EFT) without notifying the payer, although other circumstances may also result in remittance cessation. Bumps may be classified in the Remittance Cessation category if the bumps are contiguous from the current day, but there was remittance received by the provider in the past (unlike the Remittance Never Received category).

An example of remittance information that falls within the Remittance Cessation category is illustrated in FIG. 20. In the example shown in FIG. 20, a client's Electronic Remittance Advice (ERA) enrollment was switched to paper by the payer. Although the situation was corrected several days later, a large number of claims (indicated by arrow 2010) were submitted for which remittance was not received. A visual observation of the remittance information enables a user to take appropriate actions to secure the missing remittance.

A third category is “Specific Remittance Failure” in which bumps are most commonly related to individual billing batches where 100% of the claims have not received remittance and are currently at the payer. In many of these cases, it is likely that the set of claims never made it into the payer's adjudication system. An example of remittance information that falls within this category is illustrated in FIGS. 21-23. In the example shown in FIG. 21, the pattern of received remittance appears normal except for a few days indicated by arrow 2110. By examining the remittance information using the cumulative comparison view as shown in FIG. 22, a problem with remittance on the dates indicated by arrow 2110 is identified. This remittance problem is illustrated by the height of the shaded bars for these dates which far exceeds the expected remittance. A user may interact with selection region 2210 to select a date range (e.g., Jan. 13, 2010-Jan. 15, 2010) corresponding to the dates indicated by arrow 2110 in FIG. 21, and to group the remittance information by billing batch. The corresponding remittance information displayed in graph 2220 shows a pattern of either completely remitted claims (light shading) or completely open claims (dark shading) for each billing batch. Grouping the remittance information by claim format, as shown in FIG. 23 provides additional information to a user that indicates to the user that the remittance issue is restricted to claims submitted on a particular type of form. By examining the remittance information in this manner, remittance issues may be detected early in the billing cycle and appropriate actions may be taken to remedy the detected problem.

Another type of Specific Remittance Failure relates to “crossover billing events” (e.g., when Medicare forwards claims directly to Medicaid) and is illustrated in FIGS. 24-26. The remittance information illustrated in graph 2410 of FIG. 24 indicates potential problems with remittance on days indicated as 2412 and 2414. A user may investigate a cause of these remittance problems by selecting (e.g., with a mouse) one of the days 2412 or 2414 in graph 2410. FIG. 25 illustrates a user interface after a user has selected the day 2412 in graph 2410 and has grouped the claims on day 2412 by claim format. As can be seen from graph 2510, the majority of the missing remittance from day 2412 is associated with the “Unknown” claim format category, which is representative of a crossover billing event (e.g., direct Medicare to Medicaid claim billing). Graph 2510 also shows that all claims sent to a payer using the CMS1500 claim format are also still outstanding. However, as discussed above, the majority of the remittance issue on day 2412 is associated with crossover claims having the claim format “Unknown.” Identification of this common underlying remittance issue for claims billed on a particular day enables a user to rectify the remittance issue by resubmitting the appropriate claims to e.g., Medicaid.

Additionally, because a remittance issue with some crossover claims on day 2412 has been identified, a user may want to examine all claims sent to a particular payer (e.g., Medicaid) on day 2412 to determine if they succeeded or failed on that day. This analysis may be performed by grouping the claims by context as shown in FIG. 26. As indicated by the dark shaded bar 2610, a user may identify that all claims which crossed over from Medicare to Medicaid failed on day 2412 and should be resubmitted in order to receive remittance for these claims.

A fourth category is “General Remittance Failure.” This category comprises all of the bumps that were not categorized into the other categories. Although only four categories have been described, bumps may be categorized using any suitable categories and any suitable techniques and aspects of the invention are not limited in this respect.

In some embodiments, clusters identified via cluster identification process 200 or cluster identification process 300 are scored to indicate how likely it is that the claims share a common root cause. Scoring the clusters facilitates the identification of clusters that have a high likelihood of having a shared root cause issue underlying the claims in the cluster. Thus, clusters with a high score are good candidates for further investigation into the root cause. In some embodiments, clusters with a high score may be given priority so that a follow-up communication with the payer is initiated early in the resolution process. One or more algorithms may be used to determine the score for a cluster, and not all algorithms may be used to score each type of cluster. In some implementations, if multiple algorithms are used to score a cluster, only the highest score is reported, although in other implementations, an average score may be used.

Flow charts for three exemplary scoring algorithms are illustrated in FIGS. 5A-5C. A first algorithm relates to claim alarm scoring. As described above, in some embodiments, when a claim is submitted to a payer, an alarm is set by specifying an alarm date by which a response should be received from the payer. If a response is not received by the alarm date the alarm is triggered and the status of the claim may be changed, for example, to Followup. An alarm may be deactivated if a response is received before the alarm date.

An alarm score is representative of the percentage of alarms that actually fired for a given cluster pattern. In act 510, the number of possible alarms for a particular cluster pattern is determined. In act 520, the actual number of alarms that were triggered is calculated, and in act 530, the alarm score is calculated by dividing the actual number of alarms by the number of possible alarms and multiplying by 100. For example, suppose in the past sixty days there were 100 claim alarms set to be triggered for a given Medical Group::IRC cluster pattern combination and 90 of these alarms were actually triggered. In this example, a cluster based on this Medical Group and IRC would have an alarm score of 90.

Another type of scoring algorithm relates to claims that are submitted in the same billing batch. Claims submitted in the same billing batch are submitted to the payer at the same time and via the same method. In all likelihood, if one of the claims is on file with the payer, then the other claims in the billing batch should also be on file with the payer.

A process for calculating a billing batch score is illustrated in FIG. 5B. In act 540 the number of claims in the billing batch is determined. In act 550 the number of claims that belonged to the billing batch and in which no response was received is determined. The billing batch score is calculated in act 560 by dividing the number of “no response” claims by the total number of claims in the billing batch and multiplying by 100. For example, if there were 100 claims in the billing batch and no payer response was received for 80 of the claims, the cluster would have a score of 80.

Another type of scoring algorithm is based on reviewing payer responses after the status of a claim was changed to Followup. Since clusters are comprised of claims whose status was changed to Followup within a certain time period (e.g., within the past 60 days), in some cases, a payer response will have been obtained after the status of the claim was changed to Followup. For example, remittance may be received by the provider shortly after an alarm date has passed or a follow-up communication with the payer may have resolved the problem.

When working a cluster, after the problem with a claim has been resolved, the reason why the status of a claim was changed may be recorded as a “kickcode.” A process for calculating an exit information score by reviewing these post-Followup responses using information stored as kickcodes is illustrated in FIG. 5C. In act 570 the number of kickcodes for worked claims in a cluster is determined. In act 580, the count of most frequent kickcode is determined, and in act 590, the exit information score is calculated by dividing the count of the most frequent kickcode by the total number of kickcodes for worked claims and multiplying by 100. For example, suppose 100 claims have exited Followup status as the result of a payer response. In addition, suppose the most frequently used kickcode was CIP and it was employed 50 times. This would result in a score of 50 for the cluster.

In some embodiments, alarm scores and exit information scores are compared to a threshold value and are only considered valid if the scores are above the threshold value. Although three algorithms are described for scoring clusters, it should be appreciated that other types of scoring algorithms may also be employed and embodiments of the invention are not limited in this respect.

Once the clusters have been identified and scored, the results may be made available as a report to one or more users via a “Cluster Analysis Report” interface. The report allows users to generate a cross practice list of clusters which can then be “drilled into” so that their component claims can be reviewed. In addition to the score, the report comprises other information including: (1) The number of claims in Followup status, (2) The number of claims in Billed status, (3) The number of “worked” claims, and (4) The total claim count. An exemplary interface for a cluster analysis report generated by embodiments of the invention is illustrated in FIG. 6, and a corresponding report is illustrated in FIG. 7. The cluster analysis report interface in FIG. 6 comprises a plurality of fields that a user may interact with in order to select a cluster combination and other factors used to generate a report, such as the report in FIG. 7. The report may additionally comprise other information such as charts, tables, and graphs which enable a user to interact or “drill down” into the individual claims in a cluster to determine a root cause for the cluster.

As described above, Followup status refers to claims where an alarm has been triggered, indicating that the payer should be contacted and Billed status refers to claims where the alarm is set to be triggered in the near future (e.g., within the next five business days). By including both the Billed claims and the Followup claims in the cluster identification process, claims that have not yet triggered alarms may be dealt with proactively before an alarm is triggered.

An analysis process for “working” a cluster in accordance with some embodiments of the invention includes the following steps. First, a list of clusters may be reviewed for clusters with the best combination of “open” (Billed and Followup status) claims with a relatively high score. For example, in the exemplary report shown in FIG. 7, five clusters generated based on the cluster pattern “Billing Batch” are ranked according to their score. In short, clusters with the most claims and that have a significant likelihood that the claims share a common root cause are generally selected to be worked.

After a cluster has been selected to be worked, information is collected based on the specific cluster pattern which was used to generate the cluster. The information may be automatically collected from other parts of the integrated system or the information may be manually collected by a user, and embodiments of the invention are not limited in this respect. For example, if the cluster was generated based on the “Billing Batch” cluster pattern, then other claims from the same billing batch are reviewed to determine if responses have been received from the payer for those claims. The score of the cluster may be used to estimate the overall processing of the claims in a cluster. If a low number of responses is detected, the user may then review those individual claims to better understand their nature. The payer corresponding to the claims may then be contacted to verify the status of a few other claims in the billing batch.

Similarly, if the cluster was derived from the “Medical Group::Claim Submission Category” cluster pattern, then recent accounts receivable activity related to that pattern may be analyzed. Based on the initial analysis, the user may decide to contact the payer directly to confirm their analysis. For the previously mentioned “Medical Group::Claim Submission Category” cluster, if the user notices that there have been no recent payments, the payer may be contacted to verify the billing address of the medical group.

If it is determined that all claims in a cluster do not share a common root cause, the “Cluster Analysis Report” interface enables users to create subsets of the clusters. The subsets of clusters can then be analyzed in a similar manner as described above for the other clusters. For example, a user may investigate a cluster based on the medical group cluster pattern and after some analysis, determine that a root cause is shared between claims for a single provider in the medical group. A subcluster may be formed of just the claims for the single provider, and the user may then make a determination regarding whether the claims in the subcluster share a root cause. If it is determined that the claims in the subcluster do not share a root cause, the subcluster can be flagged as “Rejected,” or alternatively, the subcluster may not be added to the database. However, if it is determined that the claims in the subcluster may share a root cause, the subcluster is added to the database and is “worked” as described above.

A next step in the cluster resolution process may be to remove claims from the queue after the common cause has been addressed. This may be accomplished by changing the status of the claim to a status that more accurately describes its condition with the payer. In addition, in some embodiments, a note may be appended to the claim which reflects cluster-related findings. For example, suppose it was determined that the claims belonging to a cluster were paid by the payer and that the checks were cashed by the provider. In this example, a duplicate explanation of benefits (EOB) may be requested from the payer, the status of the claims may be updated, and a note reflecting the research may be added.

As described above, one method for changing a claim's status is to add a “kickcode” to it. A kickcode provides a general description of why the claim was moved to a particular status. In the aforementioned example, the claim may be assigned a kickcode “TRAKREMIT” indicating that the check had been cashed by the provider more than thirty days ago. This would change the status of the claims to “Billed” since a response from the payer is expected—in this case, the duplicate EOB. A more cluster-specific note such as “Spoke to John Doe at the payer, the check was cashed on Jan. 1, 2009” may also be added.

Applicants have recognized that in systems in which clusters are worked by a plurality of users in a group, it may be advantageous to automatically assign particular clusters to be worked to particular users in the group. Thus, some embodiments of the invention are directed to automatically assigning a cluster to a user in a group after the cluster is generated according to one or more cluster identification processes. By assigning clusters to particular users, it may be easier to track which clusters are being worked and by whom. Such a system may also help ensure that high-volume clusters do not go unassigned, and that two users do not work duplicate work if they work on similar, but not “duplicate” clusters. It should be appreciated that some or all of the generated clusters may be automatically assigned to a user, whereas other clusters may be assigned manually.

An exemplary workflow for a cluster analysis process that can be used work a cluster generated by the aforementioned cluster identification and generated processes according to some embodiments of the invention, is now described with reference to FIGS. 6-16. The cluster analysis process begins with a user interacting with a cluster analysis report interface as shown in FIG. 6. The user may interact with the interface to select various filtering options for generating a report of active clusters meeting specified criteria. For example, a user can filter based on certain cluster patterns or specific cluster IDs. Additionally, the user can also filter the results by including claims that meet certain characteristics (e.g., the IRC value is BCBC-MA). After selecting desired filtering options, a list of active clusters is generated as shown in FIG. 7. As described above, the list of active clusters includes information about the cluster pattern, score, and other information about the count and type of claims in each cluster.

The information listed in the report may be linked to additional information that may be helpful in enabling the user to determine a root cause for a cluster. For example, FIG. 8 shows another portion of a cluster group report which is used to provide additional details about the composition of a particular cluster that was selected from the report in FIG. 7. As can be seen from FIG. 8, a user may interact with various charts and graphs by placing a cursor over a portion of the graph or table to reveal the underlying data. If desired, a user may also examine information about claims in a cluster as shown in FIG. 9. When claims are selected, the claim ID and information about the claims including any actions taken or notes is displayed. This information may be useful to a user, among other things, to determine if multiple claims within the same cluster were handled in a similar manner. Although information for only a single claim is illustrated in FIG. 9, it should be appreciated that a report may display multiple claims.

A user may also learn about a cluster by viewing the individual claims that make up a cluster as shown in FIGS. 10 and 11. In FIG. 10, information about a cluster is displayed along with general information about the claims in the cluster. In FIG. 11, a more detailed view of all of the individual claims in the cluster. A user may use the information in the tables of FIGS. 10 and 11 to review notes made by other users who worked the claims. In addition, a user may decide to communicate with a payer regarding claims that have not yet received a response or will receive a response in the near future. By communicating with a payer, information may be collected and a hypothesis may be generated regarding a root cause for the claims in the cluster.

In some instances, a user may specify the “status” of a cluster. For example, a cluster may be marked as “Validated,” “Rejected,” or “Assigned,” to indicate that the cluster has already been worked. By indicating the status of a cluster, users will be alerted to clusters that have already been analyzed and rejected so as not to spend more time reanalyzing such clusters, whereas clusters identified as “Validated” can be quickly processed by a user.

After a user has determined a root cause for the claims in the cluster, all of the claims in the cluster can be processed en masse as illustrated in FIG. 12. An analysis system for use with clusters generated according to embodiments of the invention may comprise a “Claim Processing Wizard” which is an interface that facilitates the processing of claims in a cluster. The claim processing wizard may list the claims and enable the user to specify the actions that should be taken on the claims. Exemplary actions that may be taken include the following: 1) “Kicking” the claims with a specified kickcode—this moves the claims to another status and specifies why they were moved to the new status, and 2) adding a brief note to the claim, explaining why the particular kickcode was used. An interface for entering a note is illustrated FIG. 13A, and an interface for editing information about a claim is illustrated in FIG. 13B.

In some implementations of the claim processing wizard, notes entered by a first user may be viewable to a second user in a group of users that is working clusters. For example, notes may be made available to users in the group as a portion of a software program executed on one or more computers connected via a network. By making notes accessible to one or more other users in a group of users, common root causes that are identified by one user may be easily shared with other users in the group resulting in increased productivity and improved reporting.

The collection of claims gathered by the claim processing wizard is referred to as a “claimset.” The actions taken against claims in a claimset are taken en masse so that most or all of the claims belonging to a claimset are “kicked” at the same time. In some implementations, the claim processing wizard may accomplish this by adding a “claimnote” to each claim. For example, if claims are still in process with a payer, a claimnote with a “CIP” kickcode may be added to each claim in the claimset.

Depending on the nature of the cluster, claims outside of the cluster, but sharing similar characteristics may also be processed. This process, known as “Reach Into Billed,” may be used when the problem identified by the cluster impacts all claims recently submitted to a payer. For example, if the ID number for a provider is incorrect, then all claims submitted to the payer will be lost (or denied). In this case, any claim recently billed to the payer will need to be resubmitted, not just those whose alarm has already been triggered.

An exemplary interface for a “Reach into Billed” process for analyzing clusters generated according to some embodiments of the invention is shown in FIG. 14. In “Reach into Billed,” a user may select a time range and/or alarm date for claims to be search for that are outside of a cluster but which share characteristics with claims in the cluster. A list of potential claims is returned in response to executing this process, and a user may select some or all of the claims in the list to be processed. In both the standard and “Reach into Billed” cluster process, claims are processed en masse via “claim sets” through the claim processing wizard. This claim set functionality allows a common note and kickcode to be applied to a defined set of claims.

Since clusters are likely to persist over time users may specify how future claims matching the specified cluster pattern should be processed. For example, suppose it is determined that the previously mentioned cluster A is a valid cluster and that all claims for it should be assigned the kickcode “TRAKREMIT.” This information can be recorded and if additional claims enter Followup status that meet the conditions for belonging to cluster A, a user will know that (1) these new claims belong to a “validated” cluster group and (2) they should be assigned a kickcode of TRAKREMIT. In some embodiments, A cluster group may only remain valid for only a limited period of time. For example, if two claims both belong to the same cluster group but they entered Followup status one year apart, the reasons behind their movement into Followup status may be quite different.

Information about a cluster generated according to some embodiments of the invention may be stored using a “Cluster Group Admin” interface as illustrated in FIG. 15. The cluster group admin interface enables a user to record items such as the “recommended kickcode” for claims belonging to the cluster as well as the text of the associated claimnote. In some implementations of a cluster analysis system, the information from the cluster group admin interface may be automatically transferred throughout the cluster workflow process.

In some implementations of a cluster analysis process, a work report may be generated if the root cause determined for claims in a cluster may need to be handled by a particular user or department. For example, if a cluster has resulted from a bad “Pay-To” address, a report may be generated that can be forwarded to a user who deals with enrollment of payers and providers. Additionally, the group level information included in a work report may also be useful for a user working a cluster, as the group level information provides additional data that may be helpful in determining a root cause for the claims in the cluster. An example of a report generating interface for creating reports for clusters generated in accordance with embodiments of the invention is illustrated in FIG. 16.

Having thus described several aspects of some embodiments of this invention, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art.

Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.

The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.

Further, it should be appreciated that a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a Personal Digital Assistant (PDA), a smart phone or any other suitable portable or fixed electronic device.

Also, a computer may have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.

Such computers may be interconnected by one or more networks in any suitable form, including as a local area network or a wide area network, such as an enterprise network or the Internet. Such networks may be based on any suitable technology and may operate according to any suitable protocol and may include wireless networks, wired networks or fiber optic networks.

Also, the various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.

In this respect, the invention may be embodied as a non-transitory computer readable medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The non-transitory computer readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above.

The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. Additionally, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that when executed perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.

Computer-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments.

Also, data structures may be stored in computer-readable media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that conveys relationship between the fields. However, any suitable mechanism may be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags or other mechanisms that establish relationship between data elements.

Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

Also, the invention may be embodied as a method, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

The indefinite articles “a” and “an,” as used herein, unless clearly indicated to the contrary, should be understood to mean “at least one.”

The phrase “and/or,” as used herein, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.

As used herein, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.” “Consisting essentially of,” shall have its ordinary meaning as used in the field of patent law.

As used herein in, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only. 

1. A method of detecting remittance issues associated with a plurality of medical billing claims, the method comprising acts of: calculating, with at least one processor, an expected open rate for at least one payer based, at least in part, on historical remittance received from claims sent to a plurality of payers from a plurality of providers in a claim billing system; determining an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identifying at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorizing the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.
 2. The method of claim 1, wherein identifying at least one bump comprises identifying a plurality of bumps, wherein the method further comprises: determining whether the plurality of bumps are near to each other; and grouping the plurality of bumps when it is determined that the plurality of bumps are near to each other.
 3. The method of claim 2, wherein determining whether the plurality of bumps are near to each other comprises determining whether the bumps are contiguous or near-contiguous in time during the predetermined time range.
 4. The method of claim 2, wherein determining whether the plurality of bumps are near to each other comprises determining whether at least some of the claims contributing to the bumps are from the same provider, the same billing batch, and/or the same submission format.
 5. The method of claim 1, further comprising: assigning at least one score the at least one bump; and determining whether the at least one score is above a predetermined threshold.
 6. The method of claim 5, further comprising: discarding the particular category of remittance issue associated with the at least one bump when the at least one score is less than the predetermined threshold.
 7. The method of claim 5, wherein the at least one score is selected from a group consisting of a claim volume score, a dollar amount score, and a percentage of daily charges score.
 8. The method of claim 5, further comprising: calculating the at least one score separately for one or more factors selected from a group consisting of medical group, provider, payer, payer plan, and billing batch.
 9. The method of claim 1, further comprising: displaying the pattern of remittance during the predetermined time range using at least one user interface that enables a user to select how underlying remittance data for that least one payer is displayed.
 10. At least one computer-readable storage medium encoded with a plurality of instructions, that when executed by a computer, perform a method of detecting remittance issues associated with a plurality of medical billing claims, the method comprising acts of: calculating an expected open rate for at least one payer based, at least in part, on historical remittance received from claims sent to a plurality of payers from a plurality of providers in a claim billing system; determining an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identifying at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorizing the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.
 11. The at least one computer-readable storage medium of claim 10, wherein identifying at least one bump comprises identifying a plurality of bumps, wherein the method further comprises: determining whether the plurality of bumps are near to each other; and grouping the plurality of bumps when it is determined that the plurality of bumps are near to each other.
 12. The at least one computer-readable storage medium of claim 11, wherein determining whether the plurality of bumps are near to each other comprises determining whether the bumps are contiguous or near-contiguous in time during the predetermined time range.
 13. The at least one computer-readable storage medium of claim 11, wherein determining whether the plurality of bumps are near to each other comprises determining whether at least some of the claims contributing to the bumps are from the same provider, the same billing batch, and/or the same submission format.
 14. The at least one computer-readable storage medium of claim 10, further comprising: assigning at least one score the at least one bump; and determining whether the at least one score is above a predetermined threshold.
 15. The at least one computer-readable storage medium of claim 14, further comprising: discarding the particular category of remittance issue associated with the at least one bump when the at least one score is less than the predetermined threshold.
 16. The at least one computer-readable storage medium of claim 14, wherein the at least one score is selected from a group consisting of a claim volume score, a dollar amount score, and a percentage of daily charges score.
 17. The at least one computer-readable storage medium of claim 14, further comprising: calculating the at least one score separately for one or more factors selected from a group consisting of medical group, provider, payer, payer plan, and billing batch.
 18. The at least one computer-readable storage medium of claim 10, further comprising: displaying the pattern of remittance during the predetermined time range using at least one user interface that enables a user to select how underlying remittance data for that least one payer is displayed.
 19. A medical billing claim processing system comprising: at least one processor programmed to: calculate an expected open rate for at least one payer based, at least in part, on historical remittance received from claims sent to a plurality of payers from a plurality of providers in a claim billing system; determine an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identify at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorize the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.
 20. The medical billing claim processing system of claim 19, wherein identifying at least one bump comprises identifying a plurality of bumps, wherein the at least one processor is further programmed to: determine whether the plurality of bumps are near to each other; and grouping the plurality of bumps when it is determined that the plurality of bumps are near to each other.
 21. The medical billing claim processing system of claim 20, wherein determining whether the plurality of bumps are near to each other comprises determining whether the bumps are contiguous or near-contiguous in time during the predetermined time range.
 22. The medical billing claim processing system of claim 20, wherein determining whether the plurality of bumps are near to each other comprises determining whether at least some of the claims contributing to the bumps are from the same provider, the same billing batch, and/or the same submission format.
 23. The medical billing claim processing system of claim 19, wherein the at least one processor is further programmed to: assign at least one score the at least one bump; and determine whether the at least one score is above a predetermined threshold.
 24. The medical billing claim processing system of claim 23, wherein the at least one processor is further programmed to: discard the particular category of remittance issue associated with the at least one bump when the at least one score is less than the predetermined threshold.
 25. The medical billing claim processing system of claim 23, wherein the at least one score is selected from a group consisting of a claim volume score, a dollar amount score, and a percentage of daily charges score.
 26. The medical billing claim processing system of claim 23, wherein the at least one processor is further programmed to: calculate the at least one score separately for one or more factors selected from a group consisting of medical group, provider, payer, payer plan, and billing batch.
 27. The medical billing claim processing system of claim 19, wherein the at least one processor is further programmed to: display the pattern of remittance during the predetermined time range using at least one user interface that enables a user to select how underlying remittance data for that least one payer is displayed. 